先講清楚這是什麼、不是什麼

我一個人維運一個正在正式站上線、有真實付費訂戶的訂閱制資訊服務。它不是 side project 等級的玩具：

• 三端同步：網頁版（Vite）、iOS / Android App（React Native）、訊息平台官方帳號
• 後端：FastAPI + 雲端代管 Postgres，本機開發用 DuckDB
• 1200+ 個自動化測試，跑一輪約 7-8 分鐘
• 每天有排程在跑：資料回補、訂戶通知、AI 內容生成、到期提醒
• 真的在收錢：有訂閱等級、有點數機制、金流地基已經蓋好

而我同時還有正職。這代表這個服務的開發與維運，發生在下班後跟週末，一個人扛所有角色：後端、前端、App、DBA、SRE、客服、法遵、行銷。

聽起來不可能，對吧？五年前確實不可能。這系列要寫的就是那個讓它變成可能的差異：Claude Code 在這個服務裡不是「幫我補全程式碼的工具」，是接近合夥人職責分工的存在。

它實際在做什麼

具體一點，日常運作長這樣：

• 我描述一個功能或一個 bug，它讀過專案的踩雷紀錄（Day 3 會細講這份文件）之後動手改碼、自己寫測試、自己跑測試，紅了自己修
• 它有固定排程的巡檢任務：每天固定時段檢查程式碼品質、確認資料回補是否正常，把發現寫成報告推到獨立分支——不碰正式環境（Day 26 細講）
• 修 bug 時它會先寫一個能重現問題、會失敗的測試，確認測試真的紅了才改邏輯（Day 23 細講）
• 它踩過的坑會被記錄下來，下一次工作階段開始時自動載入，不用每次重新教（Day 24 細講）

但同樣重要的是它不做什麼：部署要不要出去、商業規則能不能改、涉及錢跟法規的判斷——這些永遠是我拍板。這條授權邊界怎麼劃，是整個系列反覆出現的主題。

30 天的地圖

為什麼值得你花 30 天看

市面上「用 AI 寫程式」的內容，九成寫的是怎麼從零生出一個 demo。demo 沒有訂戶、沒有帳單、沒有半夜炸掉的正式站、沒有「這個欄位型別改了會讓已上架的舊版 App 直接顯示亂碼」的歷史包袱。

這系列寫的是另外一成：一個活著的、會被使用者依賴、出過真實事故的系統，跟 AI agent 一起扛下來的完整紀錄。 每一條地雷都附帶「它當時怎麼炸的」，每一個設計決策都附帶「不這樣做的話後來會發生什麼」。

明天從技術選型開始：為什麼我讓本機和正式站跑兩種不同的資料庫——這個看起來違反直覺的決定，是整個「一人維運」得以成立的地基之一。